Skip to content

Fix Multiple GNUton Mount Points#577

Merged
Martinski4GitHub merged 3 commits into
devfrom
Gnuton-Mount-Point
Jun 11, 2026
Merged

Fix Multiple GNUton Mount Points#577
Martinski4GitHub merged 3 commits into
devfrom
Gnuton-Mount-Point

Conversation

@ExtremeFiretop

@ExtremeFiretop ExtremeFiretop commented Jun 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Owner

Issue reported by scootertramp on snbforums here: https://www.snbforums.com/threads/backupmon-v1-10-2-2026-may-24-backup-restore-your-router-jffs-nvram-external-usb-drive-encrypt-cifs-smb-nfs-available-in-amtm.93052/post-994663

The problem appears to be caused by multiple MerlinAU startup processes... such as "startup", "addCronJob", and "postUpdateEmail" running at the same time and reaching the GNUton webs_update.sh patch logic before being properly serialized. This created a race condition where processes shared temporary files, moved the same files, and sometimes stacked multiple bind mounts on /usr/sbin/webs_update.sh.

Below is an example of me recreating the problem using the following command:
sleep 5; /jffs/scripts/MerlinAU.sh startup & /jffs/scripts/MerlinAU.sh addCronJob & wait

Here was the result of that command:

BEFORE:

Admin@RT-AX92U-5EB0:/tmp/home/root# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi:rootfs_ubifs         69.4M     64.4M      5.1M  93% /
devtmpfs                199.5M         0    199.5M   0% /dev
tmpfs                   199.6M    384.0K    199.3M   0% /var
tmpfs                   199.6M      1.8M    197.8M   1% /tmp/mnt
mtd:bootfs                5.1M      4.2M    980.0K  81% /bootfs
mtd:data                  8.0M      3.2M      4.8M  40% /data
tmpfs                   199.6M      1.8M    197.8M   1% /tmp/mnt
tmpfs                   199.6M      1.8M    197.8M   1% /tmp
/dev/mtdblock9           63.0M      4.0M     59.0M   6% /jffs
/dev/sda1                 3.6G      1.0G      2.4G  30% /tmp/mnt/USB3
tmpfs                   199.6M      1.8M    197.8M   1% /www/index_style.css
tmpfs                   199.6M      1.8M    197.8M   1% /www/require/modules/menuTree.js
tmpfs                   199.6M      1.8M    197.8M   1% /www/state.js

TEST RUN:

Admin@RT-AX92U-5EB0:/tmp/home/root# sleep 5; /jffs/scripts/MerlinAU.sh startup & /jffs/scripts/MerlinAU.sh addCronJob & wait
mv: can't rename '/jffs/addons/MerlinAU.d/logs/RT-AX92U_FW_Update_2026-06-10_15_45_54.log': No such file or directory
mv: can't rename '/jffs/addons/MerlinAU.d/logs/RT-AX92U_FW_Update_2026-06-10_15_45_54.log.SAVED.TEMP.LOG': No such file or directory
mv: can't rename '/jffs/addons/MerlinAU.d/webs_update.sh.GNUTON.DL.TMP': No such file or directory
mv: can't rename '/jffs/addons/MerlinAU.d/webs_update.sh.GNUTON': No such file or directory

AFTER:

Admin@RT-AX92U-5EB0:/tmp/home/root# df -h
Filesystem                Size      Used Available Use% Mounted on
ubi:rootfs_ubifs         69.4M     64.4M      5.1M  93% /
devtmpfs                199.5M         0    199.5M   0% /dev
tmpfs                   199.6M    384.0K    199.3M   0% /var
tmpfs                   199.6M      1.8M    197.8M   1% /tmp/mnt
mtd:bootfs                5.1M      4.2M    980.0K  81% /bootfs
mtd:data                  8.0M      3.2M      4.8M  40% /data
tmpfs                   199.6M      1.8M    197.8M   1% /tmp/mnt
tmpfs                   199.6M      1.8M    197.8M   1% /tmp
/dev/mtdblock9           63.0M      4.0M     59.0M   6% /jffs
/dev/sda1                 3.6G      1.0G      2.4G  30% /tmp/mnt/USB3
tmpfs                   199.6M      1.8M    197.8M   1% /www/index_style.css
tmpfs                   199.6M      1.8M    197.8M   1% /www/require/modules/menuTree.js
tmpfs                   199.6M      1.8M    197.8M   1% /www/state.js
/dev/mtdblock9           63.0M      4.0M     59.0M   6% /usr/sbin/webs_update.sh
/dev/mtdblock9           63.0M      4.0M     59.0M   6% /usr/sbin/webs_update.sh

The fix was to place entire initialization (log cleanup and the GNUton download/compare/mount sequence) behind a dedicated blocking flock, while also using PID-specific temporary filenames and checking operation return codes.

Since the issue can no longer be reproduced, the concurrency race appears resolved to me?
Any ideas or suggestions you have or would like to share?

@ExtremeFiretop
Suggestion to Resolve Duplicate Mount-points
e4a99ae 
Suggestion to Resolve Duplicate Mount-points
@ExtremeFiretop
Update Version
eb173d9 
Update Version
@ExtremeFiretop
Update Dates
a42d4ac 
Update Dates
@ExtremeFiretop ExtremeFiretop changed the title Gnuton mount point Fix Multiple GNUton Mount Points Jun 10, 2026
@Martinski4GitHub

Martinski4GitHub commented Jun 11, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Issue reported by scootertramp on snbforums here: https://www.snbforums.com/threads/backupmon-v1-10-2-2026-may-24-backup-restore-your-router-jffs-nvram-external-usb-drive-encrypt-cifs-smb-nfs-available-in-amtm.93052/post-994663

Great catch by user scootertramp from the SNB Forums!!

The problem appears to be caused by multiple MerlinAU startup processes... such as "startup", "addCronJob", and "postUpdateEmail" running at the same time and reaching the GNUton webs_update.sh patch logic before being properly serialized. This created a race condition where processes shared temporary files, moved the same files, and sometimes stacked multiple bind mounts on /usr/sbin/webs_update.sh.

Nice sleuthing and great investigative work!!!
Yeah, the startup and addCronJob calls have a chance to run concurrently, and there was no lock mechanism protecting some of the initialization operations.

Below is an example of me recreating the problem using the following command: sleep 5; /jffs/scripts/MerlinAU.sh startup & /jffs/scripts/MerlinAU.sh addCronJob & wait

....

The fix was to place entire initialization (log cleanup and the GNUton download/compare/mount sequence) behind a dedicated blocking flock, while also using PID-specific temporary filenames and checking operation return codes.

You've got the right idea for the solution, but there's no need for a new, dedicated blocking flock mechanism. We already have a readily available blocking lock implementation to do what's needed for this scenario.

CORRECTION:
Actually, the separate, dedicated FLOCK blocking mechanism to protect the initialization routines is a cleaner and leaner implementation for fast operations, so it can be used here. Good call!!👍

Since the issue can no longer be reproduced, the concurrency race appears resolved to me? Any ideas or suggestions you have or would like to share?

I'll merge this PR and then submit my changes in another PR. Essentially, the approach to the solution is correct, but it needs some improvements and fine-tuning.

Martinski4GitHub
Martinski4GitHub reviewed Jun 11, 2026
View reviewed changes
Comment thread MerlinAU.sh
Martinski4GitHub
Martinski4GitHub reviewed Jun 11, 2026
View reviewed changes
Comment thread MerlinAU.sh
Martinski4GitHub
Martinski4GitHub reviewed Jun 11, 2026
View reviewed changes
Comment thread MerlinAU.sh
@Martinski4GitHub Martinski4GitHub merged commit 767770f into dev Jun 11, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Martinski4GitHub Martinski4GitHub Martinski4GitHub left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@ExtremeFiretop @Martinski4GitHub